Conversation
|
The transparent image doesn't work well with dark mode. Black text disappears. |
|
But the words are great. Nicely explains everything. |
| ### RHEL 9/10 (and current container) | ||
|
|
||
| - **Backward compatibility is guaranteed for the full life of RHEL 10.** Existing automation, documentation, and pipelines that run the container with a **bootc-image-builder** entry point remain supported. | ||
| - **Starting in RHEL 9.7/10.2** bootc-image-builder will start only shipping new major versions with each RHEL Y release. Upstream releases will no longer be backports to the RHEL 10.Y image. |
|
Looks pretty good to me, but I notice inconsistent use of image-builder, image-builder-cli and image-builder CLI in various places. I'm not even sure what to call it :) I don't think we can just call it image-builder without causing confusion with the UI, right? image-builder-cli seems like the least confusing thing to me, except when explicitly showing what command line to execute -- eg. |
The idea (at least for me is): Package: When referring to it in a sentence you can use "the image builder cli" or such 🙂. |
supakeen
left a comment
There was a problem hiding this comment.
Thanks for working on this. I have some (mostly naming) comments.
Will we make an image-builder container available downstream with RHEL 9.9/10.3 as well? If that's the case then I think a lot here can be simplified to "start using the image-builder container or package" but I've mentioned this in comments.
|
|
||
| ## Why we're deprecating bootc-image-builder | ||
|
|
||
| We are unifying the tooling so that one CLI and one container can build images from both **blueprints** (package mode) and **bootable containers** (image mode). The unified [image-builder](https://www.osbuild.org/docs/developer-guide/projects/image-builder/) project already supports building from bootc container inputs via `--bootc-ref` and related options, with functional equivalence to what bootc-image-builder provides. Maintaining two separate codebases and containers is no longer necessary; consolidating reduces maintenance and gives users a single entry point for all image-building workflows. |
There was a problem hiding this comment.
I would write this as 'so that one CLI can build images from packages, and convert bootable containers' (we're not really building the bootable container images, at least the terminology gets fuzzy here).
You can also directly link to the usage section for bootc in the image-builder docs: https://osbuild.org/docs/developer-guide/projects/image-builder/usage/#bootc
|
|
||
| ### RHEL 9/10 (and current container) | ||
|
|
||
| - **Backward compatibility is guaranteed for the full life of RHEL 10.** Existing automation, documentation, and pipelines that run the container with a **bootc-image-builder** entry point remain supported. |
There was a problem hiding this comment.
I would say "that run the bootc-image-builder container or executable remain supported".
Us switching the bootc-image-builder container to build from the image-builder-cli (with a symlink and stuff) is really an implementation detail that should be unnoticeable.
There was a problem hiding this comment.
it is an implementation detail, but given that we are archiving the bib git repo, i think it makes sense to explain. Happen to remove if there's consensus to though.
|
|
||
| - **Backward compatibility is guaranteed for the full life of RHEL 10.** Existing automation, documentation, and pipelines that run the container with a **bootc-image-builder** entry point remain supported. | ||
| - **Starting in RHEL 9.7/10.2** bootc-image-builder will start only shipping new major versions with each RHEL Y release. Upstream releases will no longer be backports to the RHEL 10.Y image. | ||
| - **Starting in RHEL 9.8/10.3**, the RHEL image-building container will be built on **image-builder-cli** (the unified implementation). It will **not** ship the original standalone bootc-image-builder binary. Instead, the container exposes a **bootc-image-builder entry point** that wraps image-builder-cli so that existing `podman run … bootc-image-builder` style invocations keep working without changing flags or workflows. A new container **image-builder** will be shipped that contains the same binary as bootc-image-builder, but without the compatibility entry point. Both the **bootc-image-builder** and **image-builder** containers will ship with the same version of image-builder-cli that is available as an rpm in respective RHEL release. |
There was a problem hiding this comment.
This is the same implementation detail that doesn't need to be mentioned. It's transparent to users.
If we do keep it then please refer specifically to the RHEL bootc-image-builder container and say it's build on image-builder.
|
|
||
| ### RHEL 11 | ||
|
|
||
| - **Only the image-builder container and CLI will be shipped.** The **bootc-image-builder** compatibility entry point will no longer be provided. |
There was a problem hiding this comment.
Replace CLI with package here and I'd say "the bootc-image-builder container and executable will no longer be available in RHEL 11".
| ### RHEL 11 | ||
|
|
||
| - **Only the image-builder container and CLI will be shipped.** The **bootc-image-builder** compatibility entry point will no longer be provided. | ||
| - Consumers must complete migration to the image-builder CLI before relying on RHEL 11 or building RHEL 11. |
There was a problem hiding this comment.
"to the image-builder package or container before".
|
|
||
| ## What you should do | ||
|
|
||
| 1. **Prefer the image-builder CLI for new work.** Use the [image-builder](https://www.osbuild.org/docs/developer-guide/projects/image-builder/) documentation and invoke **image-builder** as the container entry point (or install the CLI on the host). From RHEL 10.3 onward, the RHEL container is image-builder-cli-based; the bootc-image-builder entry point exists only for backward compatibility. |
There was a problem hiding this comment.
I would say "prefer the image-builder package or container" and skip the entrypoint stuff.
This is up for discussion and review, do not consider any part of this final at this time.